-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A first stab at a diagnostic surface temperature implementation #278
Conversation
…into ss/one-degree-take3
A very crude first calculation in where single_column_profiles.mp4There is a large difference in the ocean surface temperature (about 1 degree K), but very little in the fluxes. |
However, the surface diffusivity predicted by CATKE in the above video is single_column_profiles.mp4I need to test this on the whole surface to see if there are maybe hot or cold spots that show more difference. As it stands, the net difference in heat flux is less than 1 Probably for sea ice where timescales are faster this might matter more. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #278 +/- ##
=====================================
Coverage 0.00% 0.00%
=====================================
Files 33 34 +1
Lines 1876 1910 +34
=====================================
- Misses 1876 1910 +34 ☔ View full report in Codecov by Sentry. |
Co-authored-by: Gregory L. Wagner <[email protected]>
Shall we merge? |
There was a question about recomputing the saturation specific humidity. Was this changed and did it change the posted results? |
It's a very nice result that it converges faster by the way. |
Yep I changed it and indeed, the difference between the different solvers is much larger now in the order of 0.2 degrees instead of 0.02. I will post here another test showing the differences |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be ok to just have one Papa simulation, which uses the diagnostic surface temperautre (no need to keep the other one)
# | ||
# Where the LHS is the internal diffusive flux inside the ocean (within the boundary layer of thickness δ) | ||
# plus the (semi-implicit) outgoing longwave radiation and the RHS are the remaining atmospheric and radiative fluxes | ||
# provided explicitly. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I appreciate the comment, but which method was chosen?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
right, the fully explicit one. Should I remove the comment? Or maybe just update it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think just add a remark about what the code does now; the linearization strategy is a potential optimization that isn't taken yet
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or you can remove it :-D
AtmosphericThermodynamics.Liquid()) | ||
|
||
𝒬ₛ = AtmosphericThermodynamics.PhaseEquil_pTq(ℂ, 𝒬₀.p, θ₀, q₀) | ||
q₀ = AtmosphericThermodynamics.vapor_specific_humidity(ℂ, 𝒬ₛ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You don't want to call this again, because the "seawater" part is important --- we account for the h2O mole fraction there. Also, we may be using a different saturation parameterization than AtmosphericThermodynamics
(this is to comply with OMIP protocol)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm ok, if I remove that line the results are different (regression tests do not pass). Isn't ok that the seawater part called above?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
weird, not sure I understand what is going on then
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean, were the regression tests also incorrect?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or maybe I am confused. Does vapor_specific_humidity(ℂ, 𝒬ₛ)
compute a new specific humidity or merely extract it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I'm confused sorry, I guess vapor_specific_humidity(ℂ, 𝒬ₛ)
just extracts it. It says nothing about saturation there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But I am weirded out that it changes the result. What is the difference between the two q0?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
then probably yes, because in the main code we do:
ClimaOcean.jl/src/OceanSeaIceModels/CrossRealmFluxes/similarity_theory_turbulent_fluxes.jl
Lines 380 to 382 in 0fff4fa
q₁ = AtmosphericThermodynamics.vapor_specific_humidity(ℂ, 𝒬₁) | |
q₀ = AtmosphericThermodynamics.vapor_specific_humidity(ℂ, 𝒬₀) | |
Δq = q₁ - q₀ |
where
𝒬₀
holds the previously calculated q₀
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, on main
what we do is compute q0, and then we assemble it into a thermodynamic / dynamic state. Then we pass the whole state to the solver. Within the solver, I guess it uses vapor_specific_humidity
to extract q0 --- or at least, that's what I thought. This result suggests though that somehow q0 is changed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is changed in the vapor_specific_humidity
function. It is kind of tough to follow the thread, but it looks like the vapor_specific_humidity
builds a PhasePartition
type to calculate the humidity vapor fraction associated with the thermodynamic state
Can you also show that the difference depends on the grid spacing at the top? It should right? |
Hmm right, maybe it shouldn't depend on the grid spacing. That's helpful actually. |
This PR implements two types:
BulkTemperature
SkinTemperature
The first type is supposed to represent the default option we have know: the surface temperature is provided and equal to the temperature of "surface" model (either sea ice or ocean). This temperature is fixed and not iterated over.
The second type represents a diagnostic temperature that is diagnosed by a flux balance between the
SkinTemperature
, for the moment only a simple diffusive flux with prescribed diffusivity leading to an explicit expression for temperature, but they can become more complicated.In this second case the temperature is solved for in the
flux_balance_temperature(::SkinTemperature, T_ocean, net_external_flux)
functionThese types are provided to the
similarity_theory
as a new field namedsurface_temperature_type
. The surface temperature is then stored in aT_surface
field which is added tosimilarity_theory.fields
There is a bit of a pitfall in this implementation: it is difficult to implement temperature-dependent radiative properties, because radiative properties (that depend on i and j and the grid) are passed already computed to the solver.
I would be against passing i, j and the grid to the surface flux solver (it would entangle the solver with oceananigans so it would be difficult to swap it out with a
SurfaceFluxes.jl
solver), so we could rethink albedo and emissivity computation.